System and method for simulating resource allocation

ABSTRACT

A system and method for simulating resource allocation, where the allocation strategies which can be simulated include those of prior art but also include a large class of important allocation strategies that are not possible or not easy to simulate using prior art techniques and systems is described. A location limiting allocation strategy is also described. This strategy supports resource capacity schedules and request priorities as supported by prior art, but simultaneously supports the enforcement of allocation limits applied to a property expressed in the allocation request, namely the location of the work to be performed, or a location, resource pair to perform the work.

CROSS-REFERENCE TO RELATED APPLICATIONS

This invention claims the benefit under 35 U.S.C. s.119(e) ofprovisional application No. 60/664,973 filed Mar. 24, 2005 whichapplication is hereby incorporated herein by reference in its entirety.

STATEMENTS REGARDING FEDERALLY SPONSORED RESEARCH

Not applicable.

FIELD OF THE INVENTION

This invention is generally related to simulations and more particularlyrelated to simulations of real world scenarios.

BACKGROUND OF THE INVENTION

As is known in the art, a “simulation model” or more simply a “model” isa specialized software program used to simulate a real world scenario. Alarge class of simulation models simulate scenarios which are comprisedof individual tasks the antecedent conditions for which involve theallocation of one or more resources which may be used or needed bymultiple tasks. The resources are thus sometimes referred to as “commonresources.”

For example, a simulation of the construction of a building mightconsider carpenters and plumbers to be resources. The simulation mightbe constructed so that many individual carpentry and plumbing tasks thatare involved in constructing the building are each associated with anallocation request. Each request would describe a number of carpentersor plumbers needed to perform the associated task. The simulationproceeds only when available resources are allocated to a request,allowing the task associated with the request to be performed. Since theoutstanding requests all potentially compete for some common set ofavailable resources, there is often resource contention among therequests.

In such simulation models, the means by which resource allocationrequests are submitted and selectively granted to the requesting tasksis often referred to as the “resource allocation strategy” for thesimulation. Resource allocation also occurs in simulations of processessuch as manufacturing processes, where manufacturing tools and materialsmight be construed as resources.

Many simulation models contain mechanisms for simulating resourceallocation. These mechanisms may be provided by the simulation modelingsystem in which the model is constructed, or they may be constructed aspart of the simulation model itself, perhaps making use of anextensibility mechanism provided by the simulation modeling system. Itis also possible to construct a resource allocation mechanism usinggeneric, non-simulation specific programming techniques, as might bedone when a simulation model is built directly using an ordinaryprogramming language.

The SimProcess and SimScript and the Foresight simulation modelingsystems, for example, have resource allocation mechanisms built in,which can be invoked when constructing a simulation model. These systemsas well as the Ptolemyll system also have extensibility mechanisms whichallow the simulation modeler to provide additional logic in conjunctionwith the simulation model itself in order to implement resourceallocation mechanisms.

Whether implemented directly or by extension, in this prior art, it istypically possible to name sets of resources, describe those resourcecapacities, and to provide schedules which describe how a resourcecapacity may change over time. It may also be possible to replenish aresource, increasing its capacity during the course of simulation.Another common prior art characteristic is the ability to associate apriority value with each individual resource allocation request. In thepresence of competing outstanding requests, the allocation strategy thenallocates requests in order of descending priority. Using only resourcecapacities and request priorities as provided in the prior art, however,it is difficult, impractical or sometimes even impossible to simulate alarge class of resource allocation strategies. In particular, allocationstrategies which make reference to one or more attributes other thanresource levels or priorities of the task for which the allocation isrequired, can be extremely difficult or impossible to simulate.

Consider again a building construction simulation. It may be the casethat the building contains a location, say Room A, which is physicallytoo small to accommodate more than 3 workers of any type at any time.Therefore, the resource allocation strategy should only allocateresources to Room A if it doing so does not exceed the 3 worker limit.Given only the task attribute of priority supported by the prior art,this constraint is difficult to enforce in a simulation. An attempt todo so using just task priority would seem to entail that the priority bemodified dynamically during the course of the simulation, while therequest was still pending and unallocated. When Room A was full ofworkers, for instance, the priorities of remaining requests would haveto be adjusted so that all requests in locations other than Room A wouldhave greater priority than all outstanding Room A requests. But whensome task completes in Room A, making it possible to allocate some moreresource to Room A, some outstanding Room A request would have to haveits priority adjusted again so that Room A could receive anotherallocation without having to wait for all the work in other rooms tocomplete first. So task priority alone is incapable of expressing thelimit of resources which can be allocated to a specific location.

A similar allocation problem arises when there is a pool of resourcesavailable, say five (5) plumbers, but the simulation calls for theplumbers to behave as if they were two core crews of two (2) plumberseach, with 1 floating plumber who can participate in either crew at anytime. The prospect of dynamically changing request priorities andpossibly altering resource capacities dynamically is equally intractablein this case.

SUMMARY OF THE INVENTION

In accordance with the present invention, it has been recognized thatboth of the above examples are easily expressed in and implemented bythe techniques and systems described herein. Furthermore, the techniquesand systems described herein allow many other complex allocationstrategies to be simulated, which strategies need to make reference tosome attribute of the task other than a required resource level or atask priority. The present invention is directed toward a system andmethod for simulating resource allocation, where the allocationstrategies which can be simulated include those of prior art but alsoinclude a large class of important allocation strategies that are notpossible or not easy to simulate using prior art. Also described is aparticular type of allocation strategy referred to as a locationlimiting allocation strategy. This strategy supports resource capacityschedules and request priorities as supported by prior art systems, butsimultaneously supports the enforcement of allocation limits applied toa property expressed in the allocation request, namely the location ofthe work to be performed, and/or a location-resource pair of needed toperform the work. The invention is, furthermore, extensible, which makesit amenable to being used to implement additional allocation strategiesabove and beyond the location limiting strategy presented.

The system and techniques described herein solve, at least in part,problems of simulating resource allocation in those cases which are morecomplex than can be expressed by resource schedules and requestpriorities alone and/or the problem of simulating resource allocationwhere one or more properties of the simulated task (other than itspriority or resource requirements) enters into the allocation algorithm.Stated differently, the system and techniques described herein provide astraightforward way to express resource allocation with moresophistication than resource schedules and priorities.

Two important features of the system and techniques described herein arethe structure of the resource allocation request and the allocationstrategy.

The structure of the request (the range of things that can possibly beexpressed) must be coordinated with the means that decides when arequest is allocated. The means can be implemented in either hardware,software (e.g. a section of code) or a combination thereof. If it isdesired to allocate based on location, for instance, then the allocationrequest has to somehow mention location (or location must somehow bederivable). Thus, in one aspect, the present invention is directedtoward a technique in which a request structure is coordinated with anallocation process such that factors which may enter into the allocationcalculation are present in (or derivable from) the allocation requeststructure.

In one implementation of an allocation strategy, an interface allows asingle allocate next request operation to encapsulate all the nuances ofthe allocation strategy itself. This assumes, of course, thatappropriate surrounding infrastructure, such as the requestor andmanager as described herein, is provided. Having initialize and freeoperations makes the allocate next request operation cleaner andsimpler, but, as pointed out herein, they are technically implementableby other means. Thus, in another aspect, the present invention isdirected toward a technique wherein requests are submitted and anallocation algorithm allocates a next request if possible from among allpending requests.

In yet another aspect, the present invention is directed toward anysimulation systems and extensible mechanisms which produce/provide thesame net effect as the system described herein, regardless of whether itwas (a) done in the simulation model itself as an extension to thesimulation system, (b) done in the simulation system itself for use bythe simulation model, or (c) done without a simulation system for all,from scratch, as it were.

In yet a further aspect, the present invention is directed toward aLocation Limit Strategy which is extensible and which is adapted tocooperate with surrounding infrastructure.

It should be appreciated that the requestor and manager described hereincould be combined or separated apart in various ways and still have thesame net effect as that described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing features of this invention, as well as the inventionitself, may be more fully understood from the following description ofthe drawings in which:

FIG. 1 is a block diagram of a simulation system which includes aresource allocation strategy module;

FIG. 2 is a flow diagram which illustrates requestor flow;

FIG. 3 is a flow diagram which illustrates a manager flow of control;

FIG. 4 is a flow diagram which illustrates an allocation initializationoperation;

FIG. 5 is a flow diagram which illustrates an exemplary procedure forhandling requests received by an allocation strategy;

FIG. 6 is a flow diagram which illustrates an exemplary procedure for anallocation strategy to invoke a next request;

FIG. 7 is a flow diagram which illustrates an exemplary procedure forprocessing a free request provided to an allocation strategy;

FIG. 8 is a block diagram of exemplary data structures maintained by anallocation strategy;

FIG. 9 is a block diagram of a request structure;

FIG. 10 is a class diagram of an allocation strategy interface which maysimilar to the allocation strategy interface described above inconjunction with FIG. 1; and

FIG. 11 is an interaction diagram which illustrates one possiblesequence of interactions between two requestors, a manager and one ormore the allocation strategy threads of execution.

DETAILED DESCRIPTION OF THE INVENTION

Before describing processing and systems for performing resourceallocation, it should be appreciated that, in an effort to promoteclarity, reference is sometimes specifically made herein to allocationof resources in a construction project. And in particular, reference issometimes made herein to allocation of specific resources (e.g.carpenters and plumbers) with respect to certain tasks related to theconstruction of building.

It should be understood that such references should not be taken aslimiting the techniques and systems described herein as being for useonly with construction projects or with particular types of resources.Rather, the techniques and systems described herein may be used in anyapplication requiring allocation of resources of any type. Thus, itshould be appreciated that the techniques and systems described hereinfind application in a wide variety of different applications includingbut not limited to simulations of processes such as manufacturingprocesses, where manufacturing tools and materials might be construed asresources; construction of communications and power networks; chemicalsupply and manufacturing operations; supply chain operations,construction of aircraft (including but not limited to airplanes andhelicopters) and construction of motorized vehicles such as cars andboats.

Accordingly, those of ordinary skill in the art will appreciate that thedescription and processing described herein as taking place oncarpenters, plumbers, rooms, and tools could equally be taking place onmanufacturing tools, materials or any other resource. Likewise, in placeof or in addition to utilizing an allocation strategy such as thelocation limiting strategy described herein, an allocation strategy maybe implemented which reflects the fact that only a certain number ofpeople (e.g. engineers or manufacturing personnel) can operate orutilize a particular machine at the same time during a manufacturingoperation.

Described herein are systems and methods for simulating resourceallocation, where the allocation strategies which can be simulatedinclude both conventional allocation strategies as well as a large classof important allocation strategies that are not possible or not easy tosimulate using prior art techniques or systems. In order to promoteconciseness and clarity in the description of the concepts to beclaimed, one exemplary allocation strategy referred to as a “locationlimiting allocation strategy” is also described herein.

The location limiting allocation strategy supports resource capacityschedules (e.g. lists of how many of a particular type of resource areavailable in a given day or over any period of time as known by aresource manager) and request priorities as supported by prior artsystems and techniques, but simultaneously supports the enforcement ofallocation limits applied to a property expressed in the allocationrequest, namely the location of the work to be performed, or a location,resource pair needed to perform the work. The techniques and system are,furthermore, extensible, which makes it amenable to being used toimplement additional allocation strategies above and beyond the locationlimiting strategy presented. This is accomplished by providing resourceallocation strategy modules which are encapsulated (i.e. the data andfunctions are self contained within the strategy module) and which allcooperate with the same interface (i.e. each module mates with the sameinterface). In this way, a user (e.g. a code developer), can generateresource allocation strategy modules which perform user-definedfunctions (with each resource allocation strategy capable ofimplementing a different function) and yet which are all compatible withthe same interface and thus the same simulation processor.

It should also be appreciated that although reference is sometimes madeherein to the exemplary techniques and systems as described herein beingimplemented with “object-oriented” computer programming techniques,other implementation techniques may also be used. Object-orientedcomputer programming techniques involve the definition, creation, useand destruction of software entities referred to as “objects.” Eachobject is an independent software entity comprised of data called“attributes” and software routines called “member functions” or“methods” which manipulate the data.

One characteristic of an object is than only methods of that object canchange the data contained in the object. The term “encapsulation”describes the concept of packaging the data and methods together in anobject. Objects are thus said to encapsulate the data included as partof the object. Encapsulation protects an object's data from arbitraryand unintended use by other objects and therefore prevents an object'sdata from corruption.

To write an object-oriented computer program, a computer programmerdesigns and writes computer code for a set of “classes.” Each of theseclasses serves as a template that defines a data structure for holdingthe attributes and program instructions which perform the method of anobject. Each class also includes a means for creating an object from theclass template. The means for creating a method referred to as a“constructor.”

When a processor of a computer executes an object oriented computerprogram, the processor creates objects from the class information usingthe constructor methods. Thus, a collection of objects which areconstructed from one or more classes form the executing computerprogram.

Object oriented computer programming techniques allow computer programsto be constructed of objects that have a specified behavior. Severaldifferent objects can be combined in a particular manner to construct acomputer program which performs a particular function or provides aparticular result. Each of the objects can be built out of other objectsthat in turn can be built out of other objects. This resembles complexmachinery being built out of assemblies, subassemblies and so on.

For example, a circuit designer would not design and fabricate a videocassette recorder (VCR) transistor by transistor. Rather, the circuitdesigner would use circuit components such as amplifiers and the likeeach of which may contain hundreds or thousands of transistors. Eachcircuit component could be considered an object which performs aspecific operation. Each circuit component has specific structural andfunctional characteristics and communicates with other circuitcomponents in a particular manner. The circuit designer uses a bill ofmaterials which lists each of the different types of circuit componentswhich must be assembled to provide the VCR. Similarly, computer programscan be assembled from different types of objects each have specificstructural and functional characteristics.

In one exemplary embodiment, a particular set of classes have beendeveloped which, during program runtime, generate a particular set ofobjects to simulate allocation of resources needed in a particular jobor function.

However, although the concept of objects and encapsulation describedherein can be implemented using object-oriented computer programmingtechniques, other implementation techniques (i.e. non-object orientedtechniques) may also be used.

Referring now to FIG. 1, a simulation system 10 includes a simulationprocessor 12 adapted to receive one or a collection of work units 14 tobe simulated and a plurality of user-selectable simulation parameters16. Among the simulation parameters 16 may be found a parameterindicating that a specific choice of allocation strategies is to beused. For example, one of the simulation parameters might identify alocation limit strategy for use in a particular simulation.Alternatively, the parameters might specify use of a strategy whichhandles non-deterministic behaviors or perturbations (e.g. materials notarriving on time, weather, injury to workers, natural disasters, re-workissues (e.g. to account for quality in materials or labor).Alternatively still, a strategy which accounts for the effectiveness ofa particular resource may be used. For example, considering plumbers asa resource in a construction project, a resource manager may notice thatone particular plumber works faster that the other plumbers (e.g. byobserving resource allocation patterns using past history). Such aneffectiveness strategy may be used in conjunction with or in place ofthe basic and location limit allocation strategies. Simulationparameters may also include other parameters governing simulationbehavior that are not work unit specific. The work units 12 andsimulation parameters 14 are provided to a simulation model 16 and serveas runtime inputs to the simulation model 16.

The simulation processor 16 communicates through an interface with oneor more selected ones of a plurality of allocation strategies generallydenoted 20. In this exemplary embodiment N different allocationstrategies 20 a-20N are available to be used. Those of ordinary skill inthe art should appreciate that any number of allocation strategies (e.g.only one strategy) may be used or even available in a particularapplication. The communication between the simulation model 16 and theone or more allocation strategies 20 may be in both read and writefashion, passing data by reference or by value or a combination thereof.The interface 18 encapsulates this communication. An instance of a firstallocation strategy 20 a that implements the interface 18 is showncoupled to interface 18.

When executing a simulation, the simulation processor includes a manager22 and an allocate queue 24. Requestors 26 a, 26 b, 26 c, 26 p, 26 qfrom one or more of the work units 14 submit requests 28 a, 28 b, 28 c,28 p, 28 q to the manager 22. In a preferred embodiment, there is onemanager in a given execution of a simulation model. It is also possibleto use multiple managers, for instance, if multiple allocationstrategies are simultaneously employed in a simulation. In otherembodiments, each requestor could also include manager logic and thusperform some or all of the manager function.

It should be appreciated that, for ease and clarity of description, FIG.1 illustrates one exemplary state of the simulation processor 12 at aone specific instance of simulated time. When the manager 22 receivesthe request, the request is eventually received in a request queue 30 asa new request. For example, as indicated by the dashed lines Requests A,B, C and Q 28 a. 28 b, 28 c, 28 q, respectively, are first moved into aresource queue 30 as new requests. Requests C and Q 28 c, 28 q aresubsequently acted upon and are indicated as being allocated requests 28c, 28 q. Request 28 q is shown in phantom as an allocated request sinceit is further acted upon and is indicated as being freed. Thus, RequestsC and Q 28 c, 28 q are both shown in the “allocated” portion of theRequest queue 30.

Correspondingly, before requests A and B 28 a, 28 b are received as newrequests in the request queue 30, requestors A and B designated as 26 a,26 b are outside the allocation queue 24. Requestors 26 a, 26 b outsidethe allocation queue 24 are shown in phantom since once the requests A,B 28 a, 28 b are received as new requests in the request queue 30, therequestors A and B 26 a, 26 b are moved into the allocation queue 24.Requestor P 28 p, on the other hand, is not shown in phantom outside theallocation queue 24 since request P, 28 p has not yet been received intothe request queue 30.

Once request C 28 c is allocated, requestor 26 c is moved out of theallocation queue as indicated by reference arrow 27. Likewise, oncerequest Q 28 q is allocated, requestor 28 q is moved out of theallocation queue as indicated by reference arrow 29. Request Q 28 q issubsequently freed and thus requestor Q 26 q also becomes freed. Thus,the manager 22 releases each of the requestors 26 a-26 q as appropriate,from the respective allocation queue 24

It should be appreciated that the position of requestors within theallocation queue 24 does not indicate ordering (i.e. the system is not afirst-in-first-out system, although it is possible that requests can endup being processed in that order). Rather, the manager decides the orderin which to fill the requests based upon the allocation strategy beingused for the particular simulation. It should also be appreciated that adiscrete event scheduler is assumed to be operating in the context ofthe simulation the event scheduler schedules allocation call requests atthe appropriate simulation time. It should further be appreciated that arequestor may submit more than one request at any time. That is, onerequestor can have multiple requests in a single state (i.e. new,allocated, etc. . . . ) at any point in time.

The manager decides the manner in which to fill each request. It shouldbe appreciated that ordering is but one manner (of many possiblemanners) a manager may use to fill requests. For example, the manager isnot limited to simply ordering (or re-ordering) request. Rather, themanager may partially fill a request or may modify some portion of arequest or even an entire request to based upon an allocation strategy.

It should be appreciated that for clarity and ease of description inboth FIG. 1 itself and the corresponding text, only one allocation queue24, several requestors 26, several requests 28 and one request queue 30is shown. In a practical system (e.g. during an actual simulation), itshould be understood that many requests (possibly thousands of requestsat any one point in time), many requestors and multiple request queuesand allocation queues would exist and that requestors could flow fromone allocation queue to another as appropriate for any given resourceallocation strategy.

FIGS. 2-7 are a series of flow diagram illustrating the processingperformed by a processing apparatus which may, for example, be providedas part of a simulation system such as that described above inconjunction with FIGS. 1 and 2. The rectangular elements (e.g. block 202in FIG. 2) in the flow diagram(s) are herein denoted “processing blocks”and represent steps or instructions or groups of instructions. Some ofthe processing blocks can represent an empirical procedure or a databasewhile others can represent computer software instructions or groups ofinstructions. The diamond shaped elements in the flow diagrams (e.g.block 207 in FIG. 2) are herein denoted “decision blocks” and representsteps or instructions or groups of instructions which affect theprocessing of the processing blocks. Thus, it should be appreciated thatsome of the processing described in the flow diagrams may be implementedvia computer software while others may be implemented in a differentmanner e.g. via an empirical procedure. Alternatively, some of theprocessing blocks can represent steps performed by functionallyequivalent circuits such as a digital signal processor circuit or anapplication specific integrated circuit (ASIC).

It should also be appreciated that the flow diagrams do not depict thesyntax of any particular programming language. Rather, the flow diagramsillustrates the functional information one of ordinary skill in the artrequires to perform the processing or to fabricate circuits or togenerate computer software to perform the processing required of theparticular apparatus. It should be noted that where computer softwarecan be used, many routine program elements, such as initialization ofloops and variables and the use of temporary variables are not shown. Itwill be appreciated by those of ordinary skill in the art that unlessotherwise indicated herein, the particular sequence of steps describedis illustrative only and can be varied without departing from the spiritof the invention.

Turning now to FIG. 2, in a preferred embodiment, processing begins withone or more requestor threads of execution issuing resource allocationrequests with respect to a sequence of one or more units of work to besimulated.

Block 201 represents a loop over a sequence of work units to besimulated. For each such work unit, the requestor creates a new requestas shown in processing block 202 and assigns values to the variousparameters of the request as shown in block 203. One exemplaryassignment of request parameters is depicted in FIG. 9. Requestparameters are also discussed below. The request parameters determinethe specific nature of this particular request, such as which type ofresources are requested, how many of each, the priority of the request,the location of the work to be performed, et cetera. In a preferredembodiment, an identifier of an allocation queue, to be entered in stepis included among the request parameters.

In processing block 204, the requestor submits the request to themanager thread, described below in conjunction with FIG. 3. In apreferred embodiment, there is exactly one manager thread of execution(or more simply a “manager thread” or “manager”) in a given execution ofa simulation model, and it is a different thread from each requestor. Inequivalent embodiments, however, manager and requestor threads may bemore or less numerous (e.g. one or a plurality of threads may be used).The manager receives each such submit request call in processing blockof FIG. 3.

In processing block 205, an allocate requests call to a manager isscheduled. In the preferred embodiment, a discrete event scheduler isassumed to be operating in the context of the simulation, and processingblock 205 schedules an allocation request call at the simulation timewhich is one (1) discrete event clock tick later than the simulationtime at which the processing of processing block 204 was most recentlyperformed. If such a call is already scheduled at that time, thenprocessing block 205 becomes a no-op. Since there may be many concurrentrequestor threads in the preferred embodiment, this assures that afterall requests have been submitted at the current simulated time, themanager thread will in the next tick attempt to allocate one or more ofthe outstanding requests.

In alternative embodiments, the manager might be self-scheduled toattempt allocate requests calls at regular intervals. Anotheralternative embodiment would have the receipt of each submit requestcall initiate an allocate requests call immediately thereafter. Suchalternative embodiments may alter the pattern of allocation strategyrequests which occur over a period of time.

In processing block 206, the requestor thread enters an allocationqueue, and waits until it is released from the queue. When it isreleased, in processing block 207, the requestor thread examines therequest it had made earlier to determine if resources in the requestwere actually allocated. The reason to do this is that in someembodiments there may be many requestors waiting in the same queue, andthe release of the entire queue may occur even though not all queuedrequestors' requests have been allocated. Some embodiments may allowrequests to be partly allocated rather than completely allocated. Inthis case, the requestor may examine the request to determine ifsufficient resources have been allocated in order for the simulated workto be performed. If not, then the requestor returns to processing block206 and places itself back in the queue to wait for additionalallocation.

If instead the requestor determines that the requested resources havebeen allocated sufficiently, then processing proceeds to processingblock 208 and simulates the unit of work, using those resources whichhave been allocated. Among the side effects of simulating the unit ofwork is processing block 209, which arranges that simulation timeadvance. In the preferred embodiment, the advance of simulation time isaccomplished by asking the discrete event scheduler to schedule thedeparture of the requestor from processing block 209 at some scheduledtime in the simulated future. Other embodiments may arrange forsimulated time to advance by other means.

At processing block 210, when simulated time has advanced enough torepresent the passage of time entailed by the unit of work given theallocated resources, the requestor makes a so-called free request callto the manager, signaling that the allocated resources of this requestare now freed from this allocation. This makes the resources availableto be allocated again to another outstanding request. The managerreceives each such notification (e.g. Free Request call) in processingblock 303 of FIG. 3.

In other embodiments, a request might be freed automatically at the endof some simulated time period, or coincident with the occurrence of someother event, or it might be scheduled to be freed after some amount ofsimulated time to be indicated among the request parameters. In anyevent, it must be possible for the allocation strategy to determine whenan allocated resource is no longer required by the task to which it hasbeen allocated, and the resource thereby becomes available to otherallocations.

If the requestor has additional units of work to simulate, executionreturns to the head of the loop at processing block 201. Otherwise therequestor thread of execution ends.

Referring now to FIG. 3, in processing block 301, the managerinitializes the allocation strategy which has been chosen for thepresent execution of the simulation model (e.g. via submission of thesimulation parameters 14 described above in conjunction with FIG. 1).The choice of an allocation strategy from among a range of strategies,and the parameterization of an allocation strategy are among the aspectsof the present system and technique which support extensibility. That isto say, in the preferred embodiment, the manager respects an interface(i.e. the manager implements the interface between the allocationstrategies and the simulation processor) with the allocation strategy inwhich the manager calls the allocation strategy to initialize, toreceive requests, to allocate a next request, and to free a request.Embodiments of these three interface calls are depicted in FIGS. 4-7,respectively. Invocations of each are performed by the manager inprocessing blocks 60, 80, 70, and 76, respectively, of FIG. 3.

There are variants of this interface between the manager and theallocation strategy which might be implemented in other equivalentembodiments. For example, rather than having separate initialize andreceive requests calls, initialization of the allocation strategy mightbe assumed to occur upon first invocation of the receive requests call.

In the preferred embodiment, object oriented techniques are used toprovide a hierarchy of concrete implementations of the allocationstrategy interface. The simulation modeler (i.e. the person building thesimulation model) or the user of the simulation model can choose onesuch implementation to be used for any particular execution of thesimulation model, thereby simulating with a different allocationstrategy in each case. The implementation of the manager described inFIG. 3 is the same in each case.

In processing block 302, the manager performs its own initialization,which amounts to initializing a previous simulation time variable (e.g.a SimTime variable) and a new request list variable (e.g. a RequestListvariable). The former is to bear values of simulated time, as passed infrom the requestor submit request or free request calls, or from theallocate requests call scheduled by some requestor. This variable isinitialized in processing block 302 to have a value not greater than anythe simulated time of any event to follow in the simulation, assumedhere to be zero. The value of simulated time is assumed to neverdecrease between consecutive calls to the manager in the preferredembodiment. The latter variable holds a collection of requests, assubmitted by requestors by means of the Submit Request call. This listis initialized in processing block 302 to be empty.

In processing block 303, the manager loops over the sequence of callsmade by or scheduled to be made by requestors. For each such call, atprocessing block 304, the manager examines the simulated time passed inwith the call to determine by comparison to its own local previousSimTime value, if simulated time has progressed. By assumption,simulated time does not regress, so the only other option is thatsimulated time has not changed. In a simulation scheduled by discreteevents, the manager may receive more than one call at the same simulatedtime. If simulated time has progressed, then processing flows toprocessing block 305 in which all requests currently on the new requestlist are passed to the allocation strategy by means of the receiverequests call. Then, at processing block 306, previous SimTime isupdated with the latest value of simulated time, and the new requestlist (e.g. the new RequestList list) is emptied. If the call to themanager is discriminated at decision block 307 to be a Submit Requestcall, then the submitted request is added to the new request collection.

This mechanism insures that the allocation strategy is only made awareof newly submitted requests when all such requests for a given value ofsimulated time have been submitted by requestors. In an alternateembodiment, the manager could call the allocation strategy to receiverequests when the simulation event scheduler determined that no otherevents remained at the present simulated time, and an advance of thescheduler clock was known by other means to be imminent. The intent ofthe preferred embodiment is that the allocation strategy be able toexercise its strategy with respect to all currently outstandingrequests, at any given simulated time. The preferred embodimenttherefore prevents the allocation strategy from being called when it hasreceived some but not all of the requests submitted at any givensimulated time.

If at decision block 307, the present call is discriminated to be a freerequest call, then the freed request is simply forwarded to theallocation strategy at processing block 209.

If at decision block 307, the call is discriminated to be an allocaterequests call, then at processing block 310 the manager enters a loop inwhich the allocation strategy is invoked on each request to allocate aresource (e.g. each Allocate A Next Request) is repeatedly called on theallocation strategy until the allocation strategy determines that nomore outstanding requests can be allocated. If, at decision block 311, arequest is allocated by the strategy to the manager, then at processingblock 312 the manager examines the request to find the identifier of theallocation queue at which the requestor that submitted the request iswaiting, and releases the requestor from that queue. The loopimplemented by decision block 310 iterates in this fashion until theallocation strategy can allocate no more requests. The manager theniterates the main call loop, returning control to processing block 303.

As mentioned above, the present invention includes extensibilitycharacteristics which allow novel allocation strategies to be used forthe execution of a simulation model. This extensibility is supported bythe encapsulation of the requestor and manager logic from that of theallocation strategy.

In one exemplary embodiment, a concrete implementation of an allocationstrategy interface and associated data structures is provided by a classcalled a basic priority strategy class. This class is then extended by asubclass, called the location limiting strategy, to provide all thefunctionality of the basic priority strategy class, and in addition,functionality to allow the simulation user or modeler to associateresource allocation limits with attributes of the allocation request.The location limiting strategy will obey such limits as provided by theuser, not allocating resources on behalf of requests which would violateany declared limits.

In the preferred embodiment, four operations (or object orientedmethods) of the allocation strategy interface are implemented by thebasic priority strategy, and all but one of these operations is extendedby the location limiting strategy. The four operations are depicted inFIGS. 4-7. The decision blocks at steps 404, 604, 606, 610, and 704illustrate where the basic priority strategy is extended by the locationlimiting strategy. An affirmative branch on any of these decision blocksindicates that the location limiting strategy extensions are in effect,and a negative branch indicates that only the basic priority strategysemantics are to be applied, as chosen by the simulation modeler or userat simulation runtime.

In conjunction with these four operations, the Basic Priority Strategyalso implements two data structures (or sets of object orientedvariables born by object instances), both of which are then extended bythe location limiting strategy in the preferred embodiment. Instances ofthese data structures are depicted in FIGS. 8 and 9.

As described above, the manager calls the allocation strategy inprocessing block 301 of FIG. 3 to initialize itself, and thisinitialization operation is depicted in FIG. 4. During initialization,the allocation strategy constructs and assigns initial values to acontext data structure, an example of which is depicted in FIG. 8.

In processing block 401, the allocation strategy receives the resourceallocation schedules in preparation for beginning the simulation. Theseschedules name the types of resources which are available and how manyare available at what times during the course of the simulation. Inprocessing block 402, a list structure is created, initially empty,which will contain pending requests. In processing block 403, a counteris initialized for each resource type described in the resourceschedules, to indicate that there are initially zero elements of eachresource type currently allocated to a request, i.e. busy.

If the allocation strategy being used for the simulation is a locationlimit strategy, then at decision block 404 initialization branches toprocessing block 405, which receives a description of the limits to beenforced for this simulation from the user or the modeler. At processingblock 406, these limits are initialized to indicate that there are noresources initially busy in any location.

In processing block 305 of FIG. 3, the manager invokes the allocationstrategy to make it aware of new requests which are henceforth to beconsidered as pending and subject to possible allocation. The allocationstrategy implementation of this procedure is depicted in FIG. 5.

Referring now to FIG. 5, processing begins in processing block 501 inwhich the allocation strategy receives the requests from the manager Itshould be noted that these requests correspond to requests which themanager had each received originally from the requestor at processingblock 204 of FIG. 2. One such request which might be received by theallocation strategy is depicted in FIG. 9.

Processing block 502 adds each received request to the list of pendingrequests, and then at processing block 503, the list is sorted so thatrequests of higher priority appear earlier on the list. In a preferredembodiment, this sort process further sub-sorts requests of the samepriority, if any, so that requests made earlier in simulated time appearon the pending request list before requests of the same priority butwhich were submitted at later simulation times. After reading thedescription herein, it should be apparent to one of ordinary skill inthe art, that the further details of the sorting operation might beparameterized and assigned by the simulation user or by other means inalternative embodiments.

One possible state of the sorted pending request list is depicted asitem 811 in FIG. 8 where Request C 811 c is sorted before Request A 811a, which in turn has been sorted before Request B 811 b. Hence thepriority assigned to Request C 811 c is not less than that of Request A811 a, and Request A priority is not less than Request B priority.

In processing block 310 of FIG. 3, the manager invokes the allocationstrategy to allocate a next request from among those pending. Theallocation strategy's implementation of this operation is depicted inFIG. 6.

Referring now to FIG. 6, processing begins in processing block 601 inwhich the strategy iterates over the list of pending requests, in sortedorder as arranged by the most recent invocation of the earlier step 503.For each such request, all the resources mentioned in the request areiterated over by the inner loop as shown in processing block 602. Indecision block 603, resource schedules and busy counters are compared tothe number of resources desired by the present request to determine ifthis resource's portion of this request can be satisfied.

For example, suppose the request would like to allocate five (5)carpenters. Suppose furthermore that resource capacity scheduleindicates that there are six (6) carpenters available at the currentsimulated time. Then, if no carpenters are currently allocated to otherrequests, there are sufficiently many available that execution proceedsfrom decision block 603 by the affirmative branch (i.e. processing flowsto decision block 604).

If, on the other hand, the current value of the busy counter forcarpenters indicates that two (2) carpenters have already been allocatedto earlier requests (and not yet freed again), then six (6) less the two(2) busy is four (4), which does not allow the requested five (5)carpenters to be allocated, and hence decision block 603 proceeds by thenegative branch.

If sufficient resources are not found to be available at decision block603, then the outer loop iterates and the next pending request, if any,is examined. If sufficient resources are found to be available atdecision block 603, then processing proceeds to decision block 604. Ifthe strategy is the basic priority strategy (i.e. the strategy is notthe location limits strategy) then the negative branch is followed fromdecision block 604 and processing block iterates over any additionalresources in the present request.

If in decision block 604 a decision is made that the strategy is thelocation limit strategy, then the affirmative branch is followed atdecision block 604, and then, as shown in decision block 605,consideration is given as to whether any location limits declared by theuser prevent the requested amount of resource from being allocated.

Suppose, for instance, that the request indicates that one (1) plumberis requested for work to be performed in location room A. It has alreadybeen determined that a sufficient number of plumbers are available atthe current simulated time, given the current plumber busy count, toallocate the requested additional plumber. By examining the locationlimits and location busy counters, however, it is determined that alimit of two (2) plumbers in room A has been declared, and the locationbusy counter for plumbers in room A indicates that two (2) plumbers havealready been granted to requests in room A, and therefore an additionalplumber allocation would exceed the limit.

In this case, decision block 605 proceeds on the negative branch,returning to the outer request loop at processing block 601. If no suchlimit violations would be incurred, however, decision block 605 branchesaffirmatively, and the inner resource loop is continued at processingblock 602.

If no pending requests are found in the outer loop implemented by block601 that are satisfiable at the present simulated time, then the loopterminates and returns a negative indication to the manager, which thenproceeds on the negative branch from decision block 311 of FIG. 3.

If, however, the end of the inner loop implemented by processing block602 is ever reached, this indicates that the request being examined inthat iteration of the outer loop is one that can indeed be satisfied atthe present simulated time. Flow of control therefore proceeds todecision block 606, where, if the strategy is a location limit strategy,decision block 607 makes a final determination whether the entirerequest can be honored without violating any declared location limits.This possibility arises because, in the exemplary embodiment describedherein, the location limit strategy allows the user to declare limitsboth on resource, location pairs, and on locations singly. The meaningof a limit declared on a location alone is that the limit cannot beexceeded by any combination of resource types working in that location.

For example, and referring briefly to FIG. 8, consider the limitsdeclared in block 821 of FIG. 8. At block 822, a limit of two (2)plumbers in room A is declared. But in block 823 a limit of three (3) ofany kind of resource is declared in room A. Therefore, although nocarpenter limit is declared in room A, the location limit strategy usingthis configuration of declared limits will not be able to allocate two(2) additional carpenters to a room A request, if two plumbers arealready busy there.

Returning now to FIG. 6, if decision block 607 determines that theentire request would exceed a location limit, then processing proceedsto processing block 601 and the outer loop iterates again. If, on thecontrary, the location limit strategy is not in effect, or if it is butthe request is satisfiable in the face of all declared location limits,then at processing block 608, all of the constituent resources of therequest are iterated once again, from the beginning. At processing block609, the busy counter for the resource is incremented by the amount ofresource to be allocated.

If, at decision block 610, it is found that the location limit strategyis being used, then all applicable location busy counters areincremented at processing block 611. Otherwise if in decision block 610,it is found that the location limit strategy is not being used, theresource loop is iterated at processing block 608. When all resources inthe request have been handled in this way, the loop exits to processingblock 612, where, having been fully allocated, the request is removedfrom the list of pending requests. At processing block 613, theallocated request is returned to the manager. Having received theallocated request, the manager proceeds on the affirmative branch fromdecision block 311 of FIG. 3.

The implementation of the allocate next request operation is importantto the semantics of the allocation strategy. There are obviousextensions to the preferred embodiment which could provide additionalfunctionality or different allocation semantics. Consider, for instance,that the request priority might be irrelevant to some class ofallocation strategies. An alternative embodiment might, therefore, sortthe pending request list in some other order, such as in reverse orderof the amount of work to be performed by the request. Or, an alternativeembodiment might randomize the pending request list rather than sort it.Or, the pending list might be serviced in first-in-first-out (FIFO)order. Or, requests in the pending list might be re-ranked (orre-ordered) dynamically by the manager during the course of a simulationis order to satisfy a particular allocation strategy. Or, a particularallocation strategy might employ multiple strategies for differentrequests or at different points in time during a simulation. This isreferred to as a composite allocation strategy. Such techniques might beused to help achieve better parallelism of allocated resources, or toreduce parallelism, as the goals of the simulation required.

In the exemplary embodiment described herein, there is also no way forthe requester to describe a disjunctive allocation. That is, therequestor cannot express a request for either two (2) carpenters or,failing that, three (3) plumbers, but not both carpenters and plumbers.After reading the description provided herein, however, it should now beclear to one of ordinary skill in the art, that modifications to thecontents of the request parameters and concomitant modification to theallocate next request logic could accommodate such disjunctiveallocation requests.

Another type of extension would be means for expressing minimum andmaximum requested allocations. In some simulations, particularly when alarge task is to be undertaken, it may be beneficial to express in theallocation request a need for at least three (3) carpenters, but as manyas six (6) could be used if they are available for allocation. Theallocation strategy would then implement Allocate Next Request is such away as to allocate requests that can be honored at levels as high as themaximum requested but at levels not less than their minimum requestedlevels.

At processing block 309 of FIG. 3, the manager passes along a requestfrom the requestor to be freed to the strategy, which operation isdepicted next in FIG. 7.

Referring now to FIG. 7, At processing block 701, the strategy receivesthe request to be freed, and at processing block 702 implements aniteration over the constituent resources of the request. For each suchresource, processing block 703 decrements the respective resource busycounter. The location limit strategy branches at decision block 704 toprocessing block 705 where all relevant location busy counters aresimilarly decremented. The iteration terminates when all the resourcesallocated in the request have been accounted for in allocation strategydata

Referring now to FIG. 8, a plurality of exemplary data structures 801,811 and 821 maintained by the allocation strategy are shown. Inparticular, data structure 801 corresponds to a data structure used forresource schedules and busy counters while data structure 811corresponds to a data structure used for a pending request list. Thevalues stored in the resource schedules and busy counters datastructures 801 and the list of pending requests stored in data structure811 may be used by any basic priority strategy, including a locationlimit strategy. Only a location limit strategy, however, makes used ofthe data stored in the location limits and busy counters data structure821.

The resource schedules and busy counters data structure includes a firstcolumn 801 a under which resources are listed, a second column 801 bunder which schedule data is listed and a third column 801 c under whichbusy count values are listed. In the example of FIG. 8, under column 801a, two resources are listed (i.e. plumbers and carpenters). It should beappreciated that although only two resources are listed in this example,those of ordinary skill in the art will appreciate that a plurality ofresources could be included in data structure 801 and that each resourcecould include it's own associated schedule and busy count.

Table 802 a describes a schedule whereby five plumbers (5) are availableto be allocated to work beginning on day one (1) of the simulation whiletable 802 b describes a schedule whereby three (3) carpenters areavailable to be allocated to work beginning on day one (1) of thesimulation, and then more carpenters become available on day three (3),making a total of six (6) carpenters available thereafter. At 803, thecount of carpenter resources currently allocated to one or morerequests, and hence considered busy, is seen to be two (2). At block811, the pending request list contains three requests.

The location limits and busy counters data structure 821 includes afirst column 821 a under which locations are listed, a second column 821b under which limits for a single resource type (here, plumbers) arelisted, and a third column 821 c under limits are listed regardless ofresource type. In the example of FIG. 8, two locations (i.e. Room A,Room B) are listed under location column 821 a. It should be appreciatedthat although two locations are shown in this example, in some casesonly one location is listed while in other cases a plurality oflocations can be listed under column 821 a. The particular number oflocations, resources and limits to list in any particular case can beselected in accordance with a variety of factors including but notlimited to the particular job being considered. For example, in aconstruction project to build a structure having one-hundred (100)rooms, all one-hundred (100) some or all of the one-hundred (100) roomsmay be listed in data structure 821 and each location (i.e. each of theone-hundred (100) rooms) could have associated with it one or moreresources with limits placed on the resources (e.g. no more than 2plumber in Room A at the same time).

It should be appreciated that it is possible for locations and resourcetypes to overlap and that this can result in multiple limits beapplicable to a given resource allocation request. For example, alocation may be identified as “first floor.” This “first floor” locationmay have certain limits associated with it (e.g. no more than three (3)people may work on the first floor at the same time). If room A islocated on the first floor, then both the first floor limits as well asthe room A limits (e.g. limit three (3) 825 in the example of FIG. 8)apply to a request for resources in room A. Thus, it should now beappreciated that it is possible for any number of limits (including butnot limited to no limits) to apply to a resource allocation request.

Table 822 includes a Limit column 822 a and a Busy Count column 822 b.The Limit column 822 has a value stored therein which limits to two (2)the number of plumbers who may work in Room A at the same time. The BusyCount column 822 b has stored therein a count of two (2) which indicatesthat simulated plumber activity in Room A is currently at that limit.Similarly, as shown in Table 824 Limit column 824 a has a value storedtherein which limits to three (3) the number of plumbers who may work inRoom B at the same time (i.e. Limit column 824 a describes a limit ofthree (3) plumbers for any activity in Room B). Busy Count 824 b holdsthe value zero (0) which indicates that no plumbers are presentlyengaged in Room B.

Table 823 in column 821 c holds a value which indicates that a limit ofthree (3) of any type of resource is declared in room A, and 2 resourcesare presently active in room A. Notice that the two busy resourcesmentioned in block 823 must, by inference, be plumbers, since the busycount in block 822 indicates that there are two (2) plumbers busy. Ifanother resource was to be immediately subsequently allocated to work inroom A, it could not be another plumber, or the two (2) plumber room Alimit would be exceeded.

Referring now to FIG. 9, an exemplary request structure 901 includes acollection of parameter, value pairs in the preferred embodiment. Asshown in FIG. 9, exemplary parameters correspond to resources, priority,QueueID and Location parameter. Each of the parameters has acorresponding value. Table 902 has stored therein the value of theResources parameter, indicating how many of each type of resource arerequired to fulfill this particular request. In this example, values 902a, 902 b indicate that the resources being requested are carpenters andplumbers while values 902 c, 902 d indicate that two (2) plumbers andone (1) carpenter are requested. The zero Allocated values 902 e, 902 findicate that the request has not been allocated yet, or, equivalently,it has been allocated and freed already.

Block 903 indicates that this particular request (i.e. request 901) haspriority ten (10), allowing the request to be compared to other pendingrequests with respect to priority.

The QueueID value of Queue X in block 904 identifies the allocationqueue in which the requestor can be found waiting when, having beenallocated by the strategy, this request is returned to the manager atstep 312 of FIG. 3, and the manager releases the requestor from thequeue at step 206 of FIG. 2.

In block 905, room A is identified as the location at which the requestwork unit is to be performed once the resources described in the requesthave been allocated.

It should be appreciated that request data is first constructed when arequestor creates a new request as shown in step 202 of FIG. 2. Sincethe contents of the request must be coordinated with the allocationstrategy, the preferred embodiment includes this operation (a so-called“factory method,” in object oriented terms) in the specification of theallocation strategy interface, which is implemented by both the basicpriority strategy and the location limit strategy. Other embodimentsmight use other mechanisms, however, to ensure that the actualimplementation of the allocation strategy has a suitable request datastructure with which to issue resource allocations, and to define howthe strategy behaves if appropriate request data is not present.

Consider that the Location Limit Strategy must know the location wherethe pending request intends to perform its simulated work unit, in orderto properly enforce location limits. In the preferred embodiment, theinitially constructed request identifies no location, and it istherefore incumbent upon the requestor to assign a location in step 103of FIG. 1. If, when the Location Limit Strategy receives a request atstep 401 of FIG. 4, the request is found to identify no location, thenit is considered an error condition and the simulation is terminated.

Referring now to FIG. 10. an exemplary interface 1001 illustrating afundamental form of the interface described above includes two declaredoperations 1001 a, 1001 b. Operation 100 a is an operation to receivenew requests and operation 1001 b is an operation to allocate a nextrequest 1001 b.

Interface 1002 extends interface 1001 to add additional operations asimplemented in an exemplary embodiment. In this exemplary embodiment,the additional operations are initialization 1002 a, the freeing of anallocated request 1002 b, and a factory method to create a new requestobject 1002 c of a type appropriate for the currently instantiatedallocation strategy object. A basic priority strategy class 1003implements both of the aforementioned interfaces 1001, 1002. In additionto implementing the interface methods 1003 a, 1003 b, 1003 c, 1003 d,the basic priority strategy class 1003 includes instance variables 1004corresponding to resource schedules 1004 a, busy counters 1004 b and alist of pending requests 1004 c each of which, respectively hold theresource schedules, and busy counters and the list of pending requests.Specific values of these variables are depicted in blocks 801 and 811 ofFIG. 8.

Finally, a location limit strategy class 1006 which extends the basicpriority strategy class 1003 includes an initialize method 1006 a, amethod to allocate a next request 1006 b and a method for freeing anallocated request 1006 c. It should be appreciated that the methods ofthe basic priority strategy class 1003 which are overridden by thelocation limit strategy class 1006 are shown in FIG. 10. Also shown isan instance variable corresponding to a location limit busy counter 1006d which holds the values of the limits and busy counters associated withlocations. One specific value of this variable is depicted in block 821of FIG. 8.

Referring now to FIG. 11 an interaction diagram illustrates one possiblesequence of interactions between two requestors 1102, 1004, a manager1106, and allocation strategy threads of execution 1108 over a sequenceof simulated times 1110 a-1110 h.

During simulated time 1 1110 a, first Requestor 2, 1104 then Requestor 11102, then Requestor 2 1104 again, each submits a new request to themanager 1106.

If the manager 1106 has been scheduled for an allocate requestsoperation at the next simulated time, at time 2 1110 b, the manager 1106detects the advance of simulated time and hence passes the new requeststo the allocation strategy 1108 as indicated by reference numeral 1112.The manager 1106 then iterates over calls to the strategy to allocate anext request. In the example shown in FIG. 11, the strategy returns twosuch requests 1114 a, 1114 b, one originating from each of therequestors 1102, 1104. The manager 1106 releases each of the requestorsas appropriate from the respective allocation queue as indicated byreference numerals 1116 a, 1116 b.

At simulated time 3 1110 c, each requestor is busy simulating one task,namely the task associated with the request that has just been allocatedduring time 2 1110 b.

At time 4 1110 d, requestor 1 1102 completes the simulated task, and asindicated by reference numeral 1118 frees it to the manager 1106, whichthen passes the freed request on to the strategy 1108 as indicated byreference numeral 1120. Requestor 1 has no other submitted requestsoutstanding, and it is assumed to make no further requests. Therefore,the requestor 1 thread completes during simulated time 41110 d.

At time 5 1110 e, as indicated by reference numeral 1122 the manager hasbeen scheduled to attempt another allocate requests operation, and nowfinds that the one remaining pending request is returned from theallocation strategy 1108. The manager 1106 releases the originatingrequestor 2 1104 as indicated by reference numeral 1124.

At simulated time 6 1110 f, requestor 2 1104 is simulating both of thetasks associated with the two requests it submitted at earlier time 1.

Requestor 2 completes one of the simulated tasks at time 7, and theother at time 8, and frees each corresponding request to the manager atthe appropriate time as indicated by reference numerals 1126, 1128. Themanager 1106 forwards each of these freed requests to the strategy asindicated by reference numerals 1130, 1132. At time 8 1110 h there areno more outstanding requests and no further requests are to besubmitted, so the simulation terminates.

Having described preferred embodiments of the invention, it will nowbecome apparent to one of ordinary skill in the art that otherembodiments incorporating their concepts may also be used. It is felttherefore that these embodiments should not be limited to disclosedembodiments but rather should be limited only by the spirit and scope ofthe appended claims.

All publications and references cited herein are expressly incorporatedherein by reference in their entirety.

1. A simulation system comprising: a simulation model processorconfigured to simulate a construction project, said simulation modelprocessor having an interface and adapted to accept one or moresimulation parameters and one or more work units; and at least oneconstruction project resource allocation strategy, coupled to saidsimulation model processor, each of the at least one constructionproject resource allocation strategies for handling a resourceallocation request for the construction project, each of said at leastone construction project resource allocation strategies comprisinguser-defined logic which implements a strategy of construction projectresource allocation in response to the resource allocation request forthe construction project wherein at least one of the resource allocationstrategies corresponds to a location limiting allocation strategy.
 2. Asimulation system comprising: a simulation model processor configured tosimulate a construction project, said simulation model processor havingan interface and adapted to accept one or more simulation parameters andone or more work units; and at least one construction project resourceallocation strategy, coupled to said simulation model processor, each ofthe at least one construction project resource allocation strategies forhandling a resource allocation request for the construction project,each of said at least one construction project resource allocationstrategies comprising user-defined logic which implements a strategy ofconstruction project resource allocation in response to the resourceallocation request for the construction project wherein at least one ofthe resource allocation strategies corresponds to a location limitingallocation strategy and wherein said simulation model processor isadapted to receive one or more user-selectable simulation parameterswherein at least one of the user-selectable simulation parametersidentifies at least one of a plurality of possible allocation strategiesto use for a specific simulation.
 3. The system of claim 2 furthercomprising: a first data structure corresponding to a resource schedulesand busy counters data structure; a second data structure correspondingto a pending request list data structure; a third data structurecorresponding to a location limits and busy counters data structure andwherein each of one or more allocation strategies has a correspondingfirst, second and third data structure associated therewith and wherethe corresponding allocation strategies maintain the corresponding onesof the first, second and third data structures.
 4. The system of claim 2wherein further comprising a requestor which issues requests having arequest structure which includes one or more parameter, value pairs. 5.The system of claim 3 wherein at least one of the parameter values pairsin the request structure corresponds to a location parameter.
 6. Thesystem of claim 5 wherein the request structure further comprises: aresources parameter, a priority parameter and a queue identificationparameter; and a corresponding value place holder for each of theresources parameter, priority parameter and queue identificationparameter.
 7. The system of claim 2 further comprising a manager formaintaining a request queue and for implementing user-defined resourceallocation logic to determine a manner in which to allocate resources.8. The system of claim 7 further comprising an interface for matchinguser-defined resource allocation strategies to the simulation processor.9. The system of claim 8 further comprising an allocation queue whereinin response to a request being allocated by the allocation strategy tothe manager, the manager examines the request to find an identifier ofthe allocation queue at which the requestor that submitted the requestis waiting, and releases the requestor from that queue.
 10. A method forsimulating a resource request, the method comprising: creating a newrequest via a requestor; assigning request parameters; submitting therequest to a manager; scheduling an allocation call to the manager inresponse to the request being allocated, simulating work with allocatedresources; advancing a simulation time; and freeing a request to themanager wherein in response to the requestor creating a new request, themethod comprises constructing request data wherein the contents of thenew request are coordinated with the allocation strategy and whereincoordinating the contents of the new request with the allocationstrategy comprises including a desired operation in the specification ofan allocation strategy interface, which is implemented by at least oneallocation strategy.
 11. A method for simulating a resource request, themethod comprising: creating a new request via a requestor; assigningrequest parameters; submitting the request to a manager; scheduling anallocation call to the manager in response to the request beingallocated, simulating work with allocated resources; advancing asimulation time; freeing a request to the manager; and wherein inresponse to the requestor creating a new request, the method comprisesconstructing request data wherein the contents of the new request arecoordinated with the allocation strategy and coordinating the contentsof the new request with the allocation strategy comprises including adesired operation in the specification of an allocation strategyinterface which is implemented by at least one allocation strategyincluding both a basic priority allocation strategy and a location limitallocation strategy.
 12. The simulation system of claim 1 wherein saidsimulation model processor is adapted to receive one or moreuser-selectable simulation parameters wherein at least one of theuser-selectable simulation parameters identifies at least one of aplurality of possible allocation strategies to use for a specificsimulation.
 13. The system of claim 12 further comprising: a first datastructure corresponding to a resource schedules and busy counters datastructure; a second data structure corresponding to a pending requestlist data structure; a third data structure corresponding to a locationlimits and busy counters data structure and wherein each of one or moreallocation strategies has a corresponding first, second and third datastructure associated therewith and where the corresponding allocationstrategies maintain the corresponding ones of the first, second andthird data structures.
 14. The system of claim 12 wherein furthercomprising a requestor which issues requests having a request structurewhich includes one or more parameter, value pairs.
 15. The system ofclaim 14 wherein at least one of the parameter values pairs in therequest structure corresponds to a location parameter.
 16. The system ofclaim 15 wherein the request structure further comprises: a resourcesparameter, a priority parameter and a queue identification parameter;and a corresponding value place holder for each of the resourcesparameter, priority parameter and queue identification parameter. 17.The system of claim 12 further comprising a manager for maintaining arequest queue and for implementing user-defined resource allocationlogic to determine a manner in which to allocate resources.
 18. Thesystem of claim 17 further comprising an interface for matchinguser-defined resource allocation strategies to the simulation processor.19. The system of claim 18 further comprising an allocation queuewherein in response to a request being allocated by the allocationstrategy to the manager, the manager examines the request to find anidentifier of the allocation queue at which the requestor that submittedthe request is waiting, and releases the requestor from that queue. 20.The simulation system of claim 1 wherein the location limitingallocation strategy enforces one or more limits on the number ofresources of any type that can be allocated to perform work in aspecific location, and/or the number of resources of a specific typethat can be allocated to perform work in a specific location.
 21. Asimulation system comprising: a simulation model processor configured tosimulate a construction project, said simulation model processor havingan interface and adapted to accept one or more simulation parameters andone or more work units; and at least one construction project resourceallocation strategy, coupled to said simulation model processor, each ofthe at least one construction project resource allocation strategies forhandling a resource allocation request for the construction projectwherein at least one of the resource allocation strategies correspondsto a location limiting allocation strategy which enforces one or morelimits on the number of resources of any type that can be allocated toperform work in a specific location, and/or the number of resources of aspecific type that can be allocated to perform work in a specificlocation.